Virtual dispersive networking systems and methods

ABSTRACT

A method of communicating data using virtualization includes splitting, at endpoint software running on a first device, first data for communication to a destination device into a first plurality of data streams; selecting, at the first device by the endpoint software, a first plurality of deflects for use in communicating the first plurality of data streams; communicating each of the first plurality of data streams over a different one of the selected first plurality of deflects; splitting, at the first deflect, a particular data stream of the first plurality of data streams into a second plurality of data streams; selecting, at the first deflect, a second plurality of deflects for use in communicating the second plurality of data streams; and communicating each of the second plurality of data streams over a different one of the selected second plurality of deflects.

CROSS-REFERENCE TO RELATED APPLICATION

The present application hereby incorporates by reference the disclosureof each of U.S. provisional patent application 62/249,619 andWO/2017/079359, both from which priority is claimed.

COPYRIGHT STATEMENT

All of the material in this patent document is subject to copyrightprotection under the copyright laws of the United States and othercountries. The copyright owner has no objection to the facsimilereproduction by anyone of the patent document or the patent disclosure,as it appears in official governmental records but, otherwise, all othercopyright rights whatsoever are reserved.

BACKGROUND OF THE INVENTION

The present invention generally relates to network routing and networkcommunications.

Conventional networks, such as the Internet, rely heavily on centralizedrouters to perform routing tasks in accomplishing networkcommunications. The vulnerability and fragility of these conventionalnetworks make entities feel insecure about using them.

Further, network attacks are a common occurrence in today's cyberenvironment. Computers that are not protected by firewalls are underconstant attack. Servers are especially vulnerable due to the fact thatthey must keep a port open on their firewall to enable a connection to aclient. Hackers use this vulnerability to attack the server or computerwith a Denial of Service (DoS) attack to deny use of the server.

Cyber security is under siege from hackers. Since cyber securitysolutions can be bought, studied, and reverse engineered, hackers oftenhave had a free hand attacking and stealing information fromindividuals, companies, and nations. One major issue is that,traditionally, the security industry creates “a single lock” for all oftheir customers and assumes that no one can break the lock. However,this paradigm is not working, as companies and nations have hadinformation stolen. Recently, for example, Sony and the United StatesOffice of Program Management have been the victim of hacks. Once ahacker figures out a technique for how to break a cyber defense toolsuch as a firewall, deep packet inspection, virus protection, intrusiondetection system. IPS or others, the technique generally becomes part oftheir play book on how to hack.

Further, when vendors develop red team tools that are used to test acompany's defenses, these tools can simply be pointed at other companiesand used by hackers to break encryption and hack firewalls and intrusiondetection systems.

Needs exist for improvement in cyber security. For example, needs existfor security mechanisms that are not algorithmic in nature and which canbe modified in unique ways so that security can be achieved with simplesoftware modifications. Needs exist for system configuration to beleveraged to change operation functionality as well. One or more ofthese needs is addressed by one or more aspects of the presentinvention.

SUMMARY OF THE INVENTION

The present invention includes many aspects and features. Moreover,while many aspects and features relate to, and are described in, thecontext of network routing and network communications associated withthe Internet, the present invention is not limited to use only inconjunction with the Internet and is applicable in other networkedsystems not associated with the Internet, as will become apparent fromthe following summaries and detailed descriptions of aspects, features,and one or more embodiments of the present invention.

A first aspect relates to a method of communicating data usingvirtualization which includes splitting, at endpoint software running ona first device, first data for communication to a destination deviceinto a first plurality of data streams; selecting, at the first deviceby the endpoint software, a first plurality of deflects for use incommunicating the first plurality of data streams; communicating each ofthe first plurality of data streams over a different one of the selectedfirst plurality of deflects; splitting, at the first deflect, aparticular data stream of the first plurality of data streams into asecond plurality of data streams; selecting, at the first deflect, asecond plurality of deflects for use in communicating the secondplurality of data streams; and communicating each of the secondplurality of data streams over a different one of the selected secondplurality of deflects.

Another aspect relates to a method of communicating data usingvirtualization that includes spawning, at a first device, a firstplurality of virtual machines that each virtualizes network capabilitiesof the first device such that a first plurality of virtual networkconnections are provided; splitting, at endpoint software running on thefirst device, first data for communication to a destination device intoa first plurality of data streams; selecting, at the first device by theendpoint software, a first plurality of deflects for use incommunicating the first plurality of data streams; communicating each ofthe first plurality of data streams using a different one of the firstplurality of virtual network connections over a different one of theselected first plurality of deflects; spawning, at a first deflect ofthe selected first plurality of deflects, a second plurality of virtualmachines that each virtualizes network capabilities of the first deflectsuch that a second plurality of virtual network connections areprovided; splitting, at the first deflect, a particular data stream ofthe first plurality of data streams into a second plurality of datastreams; selecting, at the first deflect, a second plurality of deflectsfor use in communicating the second plurality of data streams; andcommunicating each of the second plurality of data streams using adifferent one of the second plurality of virtual network connectionsover a different one of the selected second plurality of deflects.

Another aspect relates to a method of communicating data usingvirtualization. The method includes spawning, at a first device, a firstplurality of virtual machines that each virtualizes network capabilitiesof the first device such that a first plurality of virtual networkconnections are provided; splitting, at endpoint software running on thefirst device, first data for communication to a destination device intoa first plurality of data streams; selecting, at the first device by theendpoint software, a first plurality of deflects for use incommunicating the first plurality of data streams; communicating each ofthe first plurality of data streams using a different one of the firstplurality of virtual network connections over a different one of theselected first plurality of deflects; spawning, at a first deflect ofthe selected first plurality of deflects, a second plurality of virtualmachines that each virtualizes network capabilities of the first deflectsuch that a second plurality of virtual network connections areprovided; receiving, at the first deflect, a first data stream of thefirst plurality of data streams; splitting, at the first deflect, thefirst data stream into a second plurality of data streams; selecting, atthe first deflect, a second plurality of deflects for use incommunicating the second plurality of data streams; communicating eachof the second plurality of data streams using a different one of thesecond plurality of virtual network connections over a different one ofthe selected second plurality of deflects; receiving, at a seconddeflect from a first set of deflects, the second plurality of datastreams; reassembling, at the second deflect, the second plurality ofdata streams into the first data stream, and communicating the firstdata stream onward to another device; receiving, at a second device froma second set of deflects, the first plurality of data streams includingthe first data stream; and reassembling, at the second device, the firstplurality of data streams into the first data.

In a feature of this aspect, spawning, at the first deflect, the secondplurality of virtual machines occurs before receiving, at the firstdeflect, the first data stream of the first plurality of data streams.

In a feature of this aspect, receiving, at the first deflect, the firstdata stream of the first plurality of data streams occurs beforespawning, at the first deflect, the second plurality of virtualmachines.

In a feature of this aspect, spawning, at the first deflect, the secondplurality of virtual machines occurs in response to receiving, at thefirst deflect, the first data stream of the first plurality of datastreams.

In a feature of this aspect, the method further comprises spawning, atthe second deflect, a third plurality of virtual machines that eachvirtualizes network capabilities of the second deflect such that a thirdplurality of virtual network connections are provided.

In a feature of this aspect, the method further comprises spawning, atthe second deflect, a third plurality of virtual machines that eachvirtualizes network capabilities of the second deflect such that a thirdplurality of virtual network connections are provided, and whereinreceiving, at the second deflect, the second plurality of data streamscomprises receiving, at the second deflect via the third plurality ofvirtual network connections, the second plurality of data streams.

In a feature of this aspect, the method further comprises spawning, atthe second device, a fourth plurality of virtual machines that eachvirtualizes network capabilities of the second device such that a fourthplurality of virtual network connections are provided.

In a feature of this aspect, the method further comprises spawning, atthe second device, a fourth plurality of virtual machines that eachvirtualizes network capabilities of the second device such that a fourthplurality of virtual network connections are provided, and whereinreceiving, at the second device, the first plurality of data streamscomprises receiving, at the second device via the fourth plurality ofvirtual network connections, the first plurality of data streams.

In a feature of this aspect, the first set of deflects comprises one ormore of the second plurality of deflects.

In a feature of this aspect, the first set of deflects comprises none ofthe second plurality of deflects.

In a feature of this aspect, the first set of deflects is the secondplurality of deflects.

In a feature of this aspect, the second set of deflects comprises one ormore of the first plurality of deflects.

In a feature of this aspect, the second set of deflects comprises noneof the first plurality of deflects.

In a feature of this aspect, the second set of deflects comprises thesecond deflect.

In a feature of this aspect, the second set of deflects does notcomprise the second deflect.

In a feature of this aspect, each deflect represents deflect softwareloaded on a distinct physical computing device.

In a feature of this aspect, two or more deflects represent deflectsoftware loaded on the same physical computing device.

In a feature of this aspect, the first device or the second device hasboth deflect software and endpoint software loaded thereon.

In a feature of this aspect, one or more deflects represent deflectsoftware loaded on a guest operating system running in a virtualmachine.

In a feature of this aspect, the method involves communication of a datastream between two virtual machines running on the same physicalcomputing device.

In a feature of this aspect, the method involves utilizing encryptionfor communications between nodes.

In a feature of this aspect, the method involves utilizing node-to-nodeencryption for communications between nodes in combination withend-to-end encryption for the entire communication from the first deviceto the second device.

In a feature of this aspect, application-level encryption is utilized.

In a feature of this aspect, public-key encryption is utilized and a keyis communicated utilizing a methodology involving splits inside ofsplits.

In a feature of this aspect, interleaving is utilized inside of one ormore splits.

In a feature of this aspect, the insertion of red herring data isutilized within one or more splits.

In a feature of this aspect, selecting, at the first device by theendpoint software, the first plurality of deflects for use incommunicating the first plurality of data streams comprises selectingthe first plurality of deflects based at least in part on networkinginformation.

In a feature of this aspect, endpoint software is loaded on a desktopcomputer.

In a feature of this aspect, endpoint software is loaded on a laptopcomputer.

In a feature of this aspect, endpoint software is loaded on a tablet.

In a feature of this aspect, endpoint software is loaded on asmartphone.

In a feature of this aspect, endpoint software is loaded on a smartwatch.

In a feature of this aspect, endpoint software is loaded on a wearablecomputing device.

In a feature of this aspect, endpoint software is loaded on a smartappliance.

In a feature of this aspect, deflect software is loaded on a desktopcomputer.

In a feature of this aspect, deflect software is loaded on a laptopcomputer.

In a feature of this aspect, deflect software is loaded on a tablet.

In a feature of this aspect, deflect software is loaded on a smartphone.

In a feature of this aspect, deflect software is loaded on a smartwatch.

In a feature of this aspect, deflect software is loaded on a wearablecomputing device.

In a feature of this aspect, deflect software is loaded on a smartappliance.

Another aspect relates to one or more computer readable media containingcomputer executable instructions for performing a disclosed method.

Another aspect relates to a system for performing a disclosed method.

Another aspect relates to software for performing a disclosed method.

In addition to the disclosed aspects and features of the presentinvention, it should be noted that the present invention furtherencompasses the various possible combinations and subcombinations ofsuch aspects and features. Thus, for example, any aspect may be combinedwith an aforementioned feature in accordance with the present inventionwithout requiring any other aspect or feature.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more preferred embodiments of the present invention now will bedescribed in detail with reference to the accompanying drawings.

FIG. 1 illustrates components of a VDR software client loaded onto aclient device in accordance with an embodiment of the present invention.

FIG. 2 illustrates how a VDR client gathers LAN routing information andqueries an external network for backbone information andapplication-specific routing information in accordance with anembodiment of the present invention.

FIG. 3 illustrates how data is added to the payload of a packet on eachof a plurality of hops in accordance with an embodiment of the presentinvention.

FIGS. 4A-C provide a simplified example of a VDR software response to anetwork attack in accordance with an embodiment of the presentinvention.

FIGS. SA-C illustrate an exemplary VDR implementation in accordance witha preferred embodiment of the present invention.

FIG. 6 includes Table 1, which table details data stored by a node inthe payload of a packet.

FIG. 7 illustrates a direct connection between two clients in accordancewith one or more preferred implementations.

FIG. 8 illustrates an exemplary process for direct transfer of a filefrom a first client to a second client in accordance with one or morepreferred implementations.

FIG. 9B illustrates an exemplary user interface for a Sharzing filetransfer application in accordance with one or more preferredimplementations.

FIG. 10 presents table 9, which illustrates potential resource reductionin accordance with one or more preferred implementations.

FIG. 11 illustrates client and server architectures in accordance withone or more preferred implementations.

FIGS. 12 and 13 illustrate exemplary processes for downloading of a filein accordance with one or more preferred implementations.

FIG. 14 illustrates the use of a dispersive virtual machine implementedas part of a software application that can be easily downloaded to adevice such as a PC, smart phone, tablet, or server.

FIG. 15 illustrates a methodology in which data to be sent from a firstdevice to another device is split up into multiple parts which are sentseparately over different routes and then reassembled at the otherdevice.

FIG. 16 illustrates how multiple packets can be sent over differentdeflects in a direct spreading of packets methodology.

FIG. 17 illustrates how multiple packets can be sent to different IPaddresses and/or ports in a hopping IP addresses and ports methodology.

FIG. 18 illustrates an exemplary system architecture configured to allowclients in a task network to access the Internet through an interfaceserver using virtual dispersive networking (VDN) spread spectrumprotocols.

FIG. 19 illustrates an exemplary system architecture configured toenable a workstation with four independent connections to the internetto send traffic using virtual dispersive networking spread spectrumprotocols to an interface server from each independent internetconnection.

FIGS. 20-23 illustrate an exemplary scenario utilizing point of entrygateways.

FIGS. 24-27 illustrate a similar scenario as that illustrated in FIGS.20-23, only one or more deflects utilized for some communications orconnections.

FIG. 28 illustrates the overlapping of data by sending it to a mobiledevice via two different wireless networks.

FIG. 29 illustrates VDN routing from a first virtual thin client toanother virtual thin client using two deflects that are configuredsimply to pass data through.

FIG. 30 illustrates a system in which deflects are configured toreformat data to another protocol.

FIG. 31A illustrates a first packet which includes data A, as well as asecond packet which includes data B.

FIG. 31B illustrates a superframe which has been constructed thatincludes both data A and data B.

FIGS. 32-33 illustrate a process in which a superframe is sent from afirst virtual thin client to a deflect.

FIG. 34 illustrates a superframe which itself includes a superframe(which includes two packets) as well as a packet.

FIG. 35 illustrates how communications are intercepted at the sessionlayer and parsed out to a plurality of links.

FIG. 36 illustrates a plurality of data paths from a first end device toa second end device.

FIG. 37 illustrates several data paths that pass through multipledeflects.

FIG. 38 illustrates how a connection from a first VTC to a second VTCthrough a second deflect is still possible even though it is notpossible to connect through a first or third deflect.

FIG. 39 illustrates a system including two end clients that arecommunicating over a network that includes three deflects.

FIGS. 40-47 illustrate exemplary systems utilizing splitting ofcommunications.

DETAILED DESCRIPTION

As a preliminary matter, it will readily be understood by one havingordinary skill in the relevant art (“Ordinary Artisan”) that the presentinvention has broad utility and application. Furthermore, any embodimentdiscussed and identified as being “preferred” is considered to be partof a best mode contemplated for carrying out the present invention.Other embodiments also may be discussed for additional illustrativepurposes in providing a full and enabling disclosure of the presentinvention. Moreover, many embodiments, such as adaptations, variations,modifications, and equivalent arrangements, will be implicitly disclosedby the embodiments described herein and fall within the scope of thepresent invention.

Accordingly, while the present invention is described herein in detailin relation to one or more embodiments, it is to be understood that thisdisclosure is illustrative and exemplary of the present invention, andis made merely for the purposes of providing a full and enablingdisclosure of the present invention. The detailed disclosure herein ofone or more embodiments is not intended, nor is to be construed, tolimit the scope of patent protection afforded the present invention,which scope is to be defined by the claims and the equivalents thereof.It is not intended that the scope of patent protection afforded thepresent invention be defined by reading into any claim a limitationfound herein that does not explicitly appear in the claim itself.

Thus, for example, any sequence(s) and/or temporal order of steps ofvarious processes or methods that are described herein are illustrativeand not restrictive. Accordingly, it should be understood that, althoughsteps of various processes or methods may be shown and described asbeing in a sequence or temporal order, the steps of any such processesor methods are not limited to being carried out in any particularsequence or order, absent an indication otherwise. Indeed, the steps insuch processes or methods generally may be carried out in variousdifferent sequences and orders while still falling within the scope ofthe present invention. Accordingly, it is intended that the scope ofpatent protection afforded the present invention is to be defined by theappended claims rather than the description set forth herein.

Additionally, it is important to note that each term used herein refersto that which the Ordinary Artisan would understand such term to meanbased on the contextual use of such term herein. To the extent that themeaning of a term used herein—as understood by the Ordinary Artisanbased on the contextual use of such term—differs in any way from anyparticular dictionary definition of such term, it is intended that themeaning of the term as understood by the Ordinary Artisan shouldprevail.

Furthermore, it is important to note that, as used herein, “a” and “an”each generally denotes “at least one.” but does not exclude a pluralityunless the contextual use dictates otherwise. Thus, reference to “apicnic basket having an apple” describes “a picnic basket having atleast one apple” as well as “a picnic basket having apples.” Incontrast, reference to “a picnic basket having a single apple” describes“a picnic basket having only one apple.”

When used herein to join a list of items. “or” denotes “at least one ofthe items.” but does not exclude a plurality of items of the list. Thus,reference to “a picnic basket having cheese or crackers” describes “apicnic basket having cheese without crackers”. “a picnic basket havingcrackers without cheese”, and “a picnic basket having both cheese andcrackers.” Finally, when used herein to join a list of items, “and”denotes “all of the items of the list.” Thus, reference to “a picnicbasket having cheese and crackers” describes “a picnic basket havingcheese, wherein the picnic basket further has crackers,” as well asdescribes “a picnic basket having crackers, wherein the picnic basketfurther has cheese.”

Further, as used herein, the term server may be utilized to refer toboth a single server, or a plurality of servers working together.

Referring now to the drawings, one or more preferred embodiments of thepresent invention are next described. The following description of oneor more preferred embodiments is merely exemplary in nature and is in noway intended to limit the invention, its implementations, or uses.

VDR

Virtual dispersive routing (hereinafter, “VDR”) relates generally toproviding routing capabilities at a plurality of client devices usingvirtualization. Whereas traditional routing calls for most, if not all,routing functionality to be carried out by centrally located specializedrouting devices, VDR enables dispersed client devices to assist with, oreven takeover, routing functionality, and thus is properly characterizedas dispersive. Advantageously, because routing is performed locally at aclient device, a routing protocol is selected by the client based uponconnection requirements of the local application initiating theconnection. A protocol can be selected for multiple such connections andmultiple routing protocols can even be utilized simultaneously. Thefragile nature of the routing protocols will be appreciated, and thusvirtualization is utilized together with the localization of routing toprovide a much more robust system. Consequently, such dispersive routingis properly characterized as virtual.

More specifically, preferred VDR implementations require that a VDRsoftware client be loaded on each client device to help control andoptimize network communications and performance. Preferably, VDR isimplemented exclusively as software and does not include any hardwarecomponents. Preferably, the basic components of a VDR software clientinclude a routing platform (hereinafter. “RP”); a virtual machinemonitor (hereinafter. “VMM”); a dispersive controller (hereinafter,“DC”); and an application interface (hereinafter, “AI”). FIG. 1illustrates each of these components loaded onto a client device. Eachof these components is now discussed in turn.

The Routing Platform (RP) and Multiple Routing Protocols

Despite eschewing the traditional routing model utilizing central pointsof control, VDR is designed to function with existing routing protocols.Supported routing protocols, together with software necessary for theiruse, are included in the routing platform component of the VDR software,which can be seen in FIG. 1. For example, the RP includes software toimplement and support the Interior Gateway Routing Protocol (“IGRP”),the Enhanced Interior Gateway Routing Protocol (“EIGRP”), the BorderGateway Protocol (“BGP”), the Open Shortest Path First (“OSPF”)protocol, and the Constrained Shortest Path First (“CSPF”) protocol. Itwill be appreciated that in at least some embodiments, a port will beneeded to allow conventional routing software to run on a chip core (forexample, a core of an Intel chip) at a client device. Preferably,multi-core components are used to allow routing protocols to be run onmultiple cores to improve overall performance.

Moreover, it will be appreciated that the ability to support multiplerouting protocols allows VDR to meet the needs of applications havingvarying mobility requirements. Applications can be supported by ad hocalgorithms such as pro-active (table driven) routing, reactive(on-demand) routing, flow oriented routing, adaptive (situation aware)routing, hybrid (pro-active/reactive) routing, hierarchical routing,geographical routing, and power aware routing. Further, the use ofmultiple protocols supports broadcasting, multi-casting, andsimul-casting. It will be appreciated that the use of multiple protocolsprovides support for multi-threaded networking as well.

The Virtual Machine Monitor (VMM) and Virtualization

It will be appreciated that virtualization is known in some computingcontexts, such as virtualization of memory and processing.Virtualization enables the abstraction of computer resources and canmake a single physical resource appear, and function, as multiplelogical resources. Traditionally, this capability enables developers toabstract development of an application so that it runs homogenouslyacross many hardware platforms. More generally, virtualization is gearedto hiding technical detail through encapsulation. This encapsulationprovides the mechanism to support complex networking and improvedsecurity that is required to enable routing at client devices.

More specifically, a virtual machine (hereinafter, “VM”) is a softwarecopy of a real machine interface. The purpose of running a VM is toprovide an environment that enables a computer to isolate and controlaccess to its services. The virtual machine monitor (VMM) component isused to run a plurality of VMs on a real machine and interface directlywith that real machine. As an example, consider a VMM on a real machinethat creates and runs a plurality of VMs. A different operating systemis then loaded onto each VM. Each VM provides a virtual interface thatwould appear to each operating system to be a real machine. The VMM runsthe plurality of VMs and interfaces with the real machine.

In a VDR implementation, a VMM is utilized to create a VM for eachdistinct connection. It is helpful to explain at this juncture that whatcomprises a connection can vary, but in general includes a transfer ofdata in the form of packets from a first end device to a second enddevice along a path (or route). It will be appreciated that a singleapplication can require multiple connections, for example, anapplication may require multiple connections because of bandwidthapplication requirements and performance requirements, in this eventeach connection preferably interfaces with its own VM and eachconnection can utilize (sometimes referred to as being tied to) the samerouting protocol or different routing protocols, even though theconnections are themselves necessitated by the same application.Similarly, although two connections may at times travel along anidentical path, the connections themselves are nevertheless distinct,and each will preferably still continue to interface with its own VM.

The Dispersive Controller (DC) and Optimizing Performance

When the client is in need of a new connection, a dispersive controllerlocated between an operating system and a driver that controls networkhardware (such as a NIC card) intercepts the request for a newconnection and tells the VMM to spawn a new VM associated with thedesired connection. The DC then queries the application interface andutilizes any information obtained to select a routing protocol fromamong those supported by the RP. This selected routing protocol,however, is currently believed to be generally useless without knowledgeof the surrounding network. To this end, the DC allows each client tofind other clients, interrogate network devices, and utilize systemresources. Thus, each VDR client is “network aware”, in that routinginformation is gathered and maintained at each client by the DC.

FIG. 2 illustrates how a VDR client 201 gathers LAN routing informationand queries an external network for backbone information andapplication-specific routing information. In response to these queries,routing information is returned. This returned routing information iscached, processed, data mined, compared to historical data, and used tocalculate performance metrics to gauge and determine the overalleffectiveness of the network. This is possible because the resourcesavailable at a VDR client will typically be greater than those availableat a conventional router.

In at least some embodiments, a VDR network functions in some wayssimilarly to a conventional network. In a conventional network, data, inthe form of packets, is sent to a router to be routed according to arouting table maintained at the router. Similarly, in a VDR network,after utilizing gathered network information to generate a routingtable, a client device utilizes this generated routing table to select aroute and transmit a packet accordingly, which packet is then receivedby another client device and routed according to that client's routingtable, and so on, until the packet reaches its destination.

However, rather than simply passing on received packets from client toclient, in a manner akin to a traditional router, VDR, via the DC,instead takes advantage of the storage and processing resourcesavailable at each client, while still remaining compatible with existingnetwork architecture, by attaching lower level protocol data to thepayload of transmitted packets for subsequent client analysis.

More specifically, when a packet is received at a VDR client, a virtualmachine intercepts the packet passed from the networking hardware (forexample, a NIC card) and places it in memory. The VDR client thenprocesses the packet data. When the data is subsequently passed on, thisprocessed data is appended to the payload of the packet together withinformation relating to the VDR client for analysis at the destination.As can be seen in FIG. 3, the result of this process is that each hopcauses additional information to be added to the payload of a packet,and thus results in a direct increase in payload size proportionate tothe number of hops taken by the packet. Specifically, each hop isbelieved to result in an increase of 35 bytes for an IPv4implementation, and 59 bytes for an IPv6 implementation. Table 1 of FIG.6 details the information stored from each layer, along with the numberof bytes allotted for each field. It will be appreciated that differentor additional information could be stored in alternative embodiments.

Currently, 128-bit addressing provides support for IPv4 and IPv6addressing, but support for additional addressing schemes iscontemplated. It will be appreciated that for a typical communicationover the Internet, i.e., one consisting of around 20 hops, the overheadappended to the payload will be around 700 bytes utilizing IPv4 andaround 1180 bytes utilizing IPv6. It is believed that, in a worst casescenario, an extra IP datagram could be required for every datagramsent. Although some of this data may seem redundant at first blush, somerepetition is tolerable and even necessary because network addresstranslation (“NAT”) can change source or destination fields. That beingsaid, it is contemplated that some implementations use caching to lowerthis overhead. Additionally, in at least some implementations, the VDRclient utilizes application specific knowledge to tailor the informationthat is appended to the needs of a specific application.

Conventionally, when a packet is received at a router, routinginformation is typically stripped off each packet by the router anddisregarded. This is because each router has limited memory and handlesan enormous number of packets. When a packet is received at adestination VDR client, however, the destination client has sufficientresources to store and process the information delivered to it.Additionally, to the extent that client resources may be taxed, the VDRclient need not always store this information in every packet received,as in at least some embodiments application knowledge provides theclient with an understanding of which packets are important toapplications running on the client. Regardless of whether some or all ofthis information delivered in the payload of each data packet isprocessed, the information that is processed is analyzed to create a“network fingerprint” of the nodes involved in the communication link.Thus. VDR software loaded on nodes along a path enables the nodes toappend information regarding a path of a packet, which in turn enablesthe generation of a network fingerprint at the destination device, whichnetwork fingerprint represents a historical record that is stored andmaintained for later forensic analysis. In addition to forensic analysisby the client, the maintenance of network information on the clientenables forensic analysis by a server as well.

The Application Interface (AI) & Application Knowledge

One of the benefits of providing routing functionality at a clientdevice is that the client is able to utilize its knowledge of theapplication initiating a connection to enhance routing performance forthat application. This knowledge is provided to the DC via anapplication interface, as can be seen in FIG. 1. Utilizing applicationknowledge to enhance routing performance could be useful to a variety ofapplications, such, as for example, computer games including massivelymultiplayer online role playing games.

The virtualization of routing functionality at a client device, asdescribed hereinabove, allows multiple routing protocols and algorithmsto be run simultaneously on a client device. Thus, the DC utilizes theapplication interface to obtain required criteria for an applicationconnection and then chooses from among the protocols and algorithmsavailable via the RP.

For example, Application “A” may need to communicate very large amountsof data, and thus require a routing protocol that optimizes bandwidth,while Application “B” may only need to communicate very small amounts ofdata at very fast speeds, and thus require a routing protocol thatminimizes latency irrespective of bandwidth. A traditional router cannottell the difference between packets originating from Application “A” andthose originating from Application “B”, and thus will utilize the samerouting protocol for packets from each application. A VDR client,however, is aware of applications running locally, and thus can beaware, through the AI, of various connection criteria for eachapplication. These connection criteria can then be utilized by the VDRclient in selecting a routing protocol or algorithm. Furthermore, asdescribed hereinabove, both the selected routing protocol and theoriginating application associated with a packet can be communicated toother client nodes via data appended to the payload of the packet. Thus,the protocol selected at a source client can be utilized to route thepacket throughout its path to a destination client. Further, becausevirtualization allows multiple routing protocols to be run on a singleclient, each application can utilize its own routing protocol.

Moreover, a VDR client can utilize knowledge of the path of a specificconnection to further optimize performance. Because a networkfingerprint can be gathered detailing the nodes in a communication path,a VDR client running on a client device can analyze each networkfingerprint to determine whether the associated connection satisfies theconnection criteria of the application desiring to utilize theconnection. If the connection does not satisfy the connection criteria,then the client can attempt to find a connection that does satisfy thecriteria by switching to a different protocol and/or switching to adifferent first node in its routing table. Combinations utilizingvarious protocols and selecting a variety of first nodes can beattempted, and the resultant paths evaluated until a path is found thatdoes satisfy connection criteria. Additionally, combinations utilizingvarious protocols and selecting a variety of first nodes can be utilizedto create route redundancy. Such route redundancy can provide to anapplication both higher bandwidth and controllable quality of service.

Although connection criteria for source and destination clients willoften be identical, there are many situations where this will not be thecase. For example, if one client is downloading streaming video fromanother client, then the connection requirements for each client willlikely not be identical. In this and other situations, connectionsbetween two clients may be asymmetrical, i.e., client “A” transmitspackets to client “B” over path 1, but client “B” transmits packets toclient “A” over path 2. In each case, because path information gleanedfrom the payload of packets is stored and processed at the destinationclient, the evaluation of whether the path meets the required connectioncriteria is made at the destination client. In the example above, client“B” would determine whether path 1 satisfies its application'sconnection criteria, while client “A” would determine whether path 2satisfies its application's connection criteria.

Perhaps the epitome of a connection that does not satisfy connectioncriteria is a broken, or failed, connection. In the event of aconnection break, VDR enjoys a significant advantage over moretraditional routing. Conventionally, recognition of a connection breakwould require a timeout at an upper level application, with either thepath being re-routed subsequent to the timeout or a connection failuremessage being presented to a user. A VDR client, however, is aware ofgenerally how long it should take to receive a response to a transmittedcommunication, and can utilize this awareness to speed up routeconvergence for additional network connections to insure applicationrobustness and performance requirements, performance requirements beingdefined as criteria that must be met to allow the application to runproperly, i.e., video conferencing can't wait too long for packets toshow up or else the audio “crackles” and the image “freezes.” Forexample, a VDR client may be aware that it should receive a response toa communication in 500 ms. If a response has not been received after 500ms, the VDR client can initiate a new connection utilizing a differentrouting protocol and/or first node as outlined above with respect tofinding a satisfactory connection path.

In addition to performance optimization, application knowledge can alsobe utilized to enhance network security. For example, an application mayhave certain security requirements. A VDR client aware of theserequirements can create a “trusted network” connection that can be usedto transfer information securely over this connection in accordance withthe requirements of the application. A more traditional routing schemecould not ensure such a trusted connection, as it could notdifferentiate between packets needing this secure connection and otherpackets to be routed in a conventional manner.

But before elaborating on security measures that may be built in to aVDR implementation, it is worth noting that a VDR client is able to workin concert with an existing client firewall to protect software andhardware resources. It will be appreciated that conventional firewallsprotect the flow of data into and out of a client and defend againsthacking and data corruption. Preferably, VDR software interfaces withany existing client firewall for ease of integration with existingsystems, but it is contemplated that in some implementations VDRsoftware can include its own firewall. In either implementation, the VDRsoftware can interface with the firewall to open and close ports asnecessary, thereby controlling the flow of data in and out.

In addition to this firewall security, by utilizing applicationknowledge the VDR software can filter and control packets relative toapplications running on the client. Thus, packets are checked not onlyto ensure a correct destination address, but further are checked toensure that they belong to a valid client application.

One way VDR software can accomplish this is by utilizing “spiders” tothread together different layers of the protocol stack to enable datacommunication, thereby reducing delays and taking advantage of networktopologies. Each spider represents software that is used to analyze datafrom different layers of the software stack and make decisions. Thesethreaded connections can be used to speed data transfer in staticconfigurations and modify data transfer in dynamic circumstances. As anexample, consider a client device running a secure email applicationwhich includes a security identification code. Packets for thisapplication include a checksum that when run will come up with thisidentification code. A spider would allow this upper level applicationsecurity identification code to be connected to the lower layer. Thus,the lower layer could run a checksum on incoming packets and discardthose that do not produce the identification code. It will beappreciated that a more complex MD5 hash algorithm could be utilized aswell.

Moreover, because the VDR software is knowledgeable of the applicationrequiring a particular connection, the software can adaptively learn andidentify atypical behavior from an outside network and react byquarantining an incoming data stream until it can be verified. Thisability to match incoming data against application needs and isolate anypotential security issues significantly undermines the ability of ahacker to gain access to client resources.

Additionally, when such a security issue is identified, a VDR client cantake appropriate steps to ensure that it does not compromise thenetwork. Because a VDR client is network aware and keeps track of otherclients that it has been communicating with, when a security issue isidentified, the VDR client can not only isolate the suspect connection,the VDR client can further initiate a new connection utilizing adifferent routing protocol and/or first node as outlined above withrespect to finding a satisfactory connection path. Alternatively, oradditionally, the VDR client could simply choose to switch protocols onthe fly and communicate this switch to each client with which it is incommunication.

FIGS. 4A-C provide a simplified example of such action for illustrativeeffect. In FIG. 4A, VDR client 403 is communicating with VDR client 405over connection 440. In FIG. 4B, external computer 411 tries to alterpacket 491 transmitted from client 403 to client 405. Client 405 runs ahashing algorithm on the received packet 491 and identifies that it hasbeen corrupted. Client 405 then quarantines packets received viaconnection 440 and, as can be seen in FIG. 4C, establishes a newconnection 450 with client 403.

Upon discovery of an “attack” on a network or specific networkconnection, a VDR client can monitor the attack, defend against theattack, and/or attack the “hacker”. Almost certainly, a new, secureconnection will be established as described above. However, afterestablishing a new connection, the VDR client can then choose to simplykill the old connection, or, alternatively, leave the old connection upso that the attacker will continue to think the attack has some chanceof success. Because each connection is virtualized, as describedhereinabove, a successful attack on any single connection will not spillover and compromise the client as a whole, as crashing the VM associatedwith a single connection would not affect other VMs or the client deviceitself. It is contemplated that a VDR client will attempt to trace backthe attack and attack the original attacker, or alternatively, andpreferably, communicate its situation to another VDR client configuredto do so.

An Exemplary Implementation

Traditionally, wired and wireless networks have tended to be separateand distinct. Recently, however, these types of networks have begun tomerge, with the result being that the routing of data around networkshas become much more complex. Further, users utilizing such a mergednetwork desire a high level of performance from the network regardlessof whether they are connected wirelessly or are connected via a fixedline. As discussed hereinabove. VDR enables a client to monitor routinginformation and choose an appropriate routing protocol to achieve thedesired performance while still remaining compatible with existingnetwork architecture. VDR can be implemented with wired networks,wireless networks (including, for example, Wi-Fi), and networks havingboth wired and wireless portions.

FIG. 5A illustrates an exemplary local area network 510 (hereinafter.“LAN”) utilizing VDR. The LAN 510 includes three internal nodes511,513,515, each having VDR software loaded onto a client of therespective node. The internal nodes 511,513,515 can communicate with oneanother, and further can communicate with edge nodes 512,514,516,518,each also having VDR software loaded onto a client of the respectivenode. The coverage area 519 of the LAN 510 is represented by a dottedcircle. It will be appreciated that the edge nodes 512,514,516,518 arelocated at the periphery of the coverage area 519. The primarydistinction between the internal nodes 511,513,515 and the edge nodes512,514,516,518 is that the internal nodes 511,513,515 are adapted onlyto communicate over the LAN 510, while the edge nodes 512,514,516,518are adapted to communicate both with the internal nodes 511,513,515 andwith edge nodes of other LANs through one or more wide area networks(hereinafter, “WANs”). As one of the nodes 511,513,515 moves within theLAN 510 (or, if properly adapted, moves to another LAN or WAN), VDRallows it to shift to ad hoc, interior, and exterior protocols. Thisability to shift protocols allows the node to select a protocol whichwill provide the best performance for a specific application.

FIG. 5B illustrates an exemplary path between node 513 in LAN 510 andnode 533 in LAN 530. It will be appreciated that an “interior” protocolis utilized for communications inside each LAN, and an “exterior”protocol is utilized for communications between edge nodes of differentLANs. Thus, it will likewise be appreciated that each edge node mustutilize multiple protocols, an interior protocol to communicate withinterior nodes, and an exterior protocol to communicate with other edgenodes of different LANs. Further, at any time an adhoc protocol could beset up which is neither a standard interior nor exterior protocol.

In FIG. 5B, LAN 510 and LAN 530 are both using CSPF as an interiorprotocol, while LAN 520 and LAN 540 are utilizing EIGRP as an interiorprotocol. All edge nodes of each of the LANs 510,520,530 are connectedto a WAN utilizing BGP to communicate between edge nodes.

The exemplary path between node 513 and node 533 includes node 515, edgenode 518, edge node 522, node 521, node 523, node 525, edge node 528,edge node 534, and node 531. Further, because a particular protocol wasnot selected and propagated by the transmitting node, this connectionutilizes CSPF for internal communications within LAN 510 and LAN 530.EIGRP for internal communications within LAN 520, and BGP for externalcommunications between edge nodes. At one or both end nodes, the VDRsoftware can analyze this information and determine whether thecombination of protocols along this path is satisfactory for thecommunicating application. It will be appreciated that the VDR softwarecan further analyze the information gathered and determine whether thepath meets application requirements for throughput, timing, security,and other important criteria.

In a static environment, this path may represent a connection that meetsapplication requirements and thus no further adjustment would be needed.However, if a network outage were to occur, a network or a node were tomove, or another dynamic event was to occur, the path could need to bealtered.

For example, if LAN 520 were to move out of range, node 533 mightanalyze the path information appended to a packet received after themovement and determine that increased latency resulting from thismovement rendered this path unsuitable per application requirements.Node 533 would then attempt to establish a new connection utilizing adifferent route that would satisfy application requirements. FIG. 5Cillustrates such a new connection, which remains between node 513 andnode 533, but rather than being routed through LAN 520 as with the pathillustrated in FIG. 5B, the path is instead routed through LAN 540.

It will be appreciated that the ability to influence path selectionbased on client application needs significantly enhances theperformance, flexibility, and security of the network.

It will further be appreciated from the above description that one ormore aspects of the present invention are contemplated for use with end,client, or end-client devices. A personal or laptop computer areexamples of such a device, but a mobile communications device, such as amobile phone, or a video game console are also examples of such adevice. Still further, it will be appreciated that one or more aspectsof the present invention are contemplated for use with financialtransactions, as the increased security that can be provided by VDR isadvantageous to these transactions.

Network Data Transfer

It will be appreciated that the transmission of data over the Internet,or one or more similar networks, often utilizes precious serverprocessing, memory, and bandwidth, as the data is often delivered from,or processed at, a server. In implementations in accordance with one ormore preferred embodiments of the present invention, some of this serverload is mitigated by use of a direct connection between two end-userdevices, such as, for example two end-user devices having virtualizedrouting capabilities as described hereinabove. Preferably, packets arethen routed between the two end-user devices without passing through aconventional server.

Notably, however, although transferred data packets do not pass througha server, a server may still be utilized to establish, monitor, andcontrol a connection, as illustrated in FIG. 7. Specifically. FIG. 7illustrates two clients and an IP server which determines that theclients are authorized to communicate with one another, and which passesconnection information to the clients that is utilized to establish adirect connection between the clients. Importantly, the IP server is notinvolved in this direct connection, i.e. data transferred via thisdirect connection is not routed through or processed by the IP server,which would require the use of additional resources of the IP server.

It will be appreciated that, in some networks, a firewall may be setupto prevent an end-user device from accepting connections from incomingrequests. There are three basic scenarios that can occur. In a firstcase, there is no firewall obstruction. In the first case, either clientcan initiate the connection for the direct connect. In a second case, asingle client has a firewall obstructing the connection. In this case,the client that is obstructed from accepting the connection isinstructed by the IP Server to initiate the connection to the clientthat is unobstructed by the firewall. In a third case, both clients havefirewalls obstructing the connection. In this case, a software router,or software switch, is used to accept the connection of the two clientsand pass the packets through to the clients directly. Notably, thissoftware router truly acts as a switch, and does not modify the payloadas it passes the packet through. In a preferred implementation, asoftware router is implemented utilizing field programmable gate arrays(FPGAs) or other specific hardware designed to implement suchcross-connect functionality.

A preferred system for such a described direct connection includes oneor more end-user devices having client software loaded thereon, an IPserver, or control server, having server software loaded thereon, andone or more networks (such as, for example Internet, Intranet orExtranet supported by Ethernet, Mobile Phone data networks. e.g. CDMA.WiMAX, GSM. WCDMA and others, wireless networks, e.g. Bluetooth, WiFi,and other wireless data networks) for communication.

In a preferred implementation, client software installed at an end-userdevice is configured to communicate with an IP server, which associates,for example in a database, the IP address of the end-user device with aunique identification of a user, such as an email address, telephonenumber, or other unique identification. The client then periodically“checks in” with the IP server and conveys its IP address to the server,for example by providing its IP address together with the uniqueidentification of the user. This checking in occurs when the client is“turned on”, e.g. when the end-user device is turned on or when theclient software is loaded, as well as when the IP address has changed,or upon the occurrence of any other network event that would change thepath between the client and server, or in accordance with otherconfigured or determined events, times, or timelines, which may beuser-configurable.

By collecting, and updating, the current IP address of a user, otherusers may communicate with that user as the user moves from place toplace. The IP server thus acts as a registry providing updated IPaddresses associated with users. This capability also enables multipledevice delivery of content to multiple end-user devices a userdesignates or owns.

Preferably, such functionality is utilized in combination withvirtualized routing capability as described hereinabove. Specifically,it will be appreciated that, currently. Internet communications utilizesessions, and that upon being dropped, e.g. due to a lost connection, anew session must be initialized.

In a preferred implementation, however, rather than having tore-initiate a new session, for example upon obtaining a new IP address,a new session is created and data is transferred from the old session tothe new session while maintaining the state of the old session. In thisway, a near-seamless transition is presented to a user between an oldsession and a new session. For example, a user might be connected viatheir mobile device to a Wi-Fi connection while they are on the move.They might move out of range of the Wi-Fi connection, but still be inrange of a cellular connection. Rather than simply dropping theirsession, a new session is preferably created, and data from the oldsession copied over, together with the state of the old session. In thisway, although the end-user device is now connected via a cellularconnection, rather than via a Wi-Fi connection, the user's experiencewas not interrupted.

One Client to One Client—File Transfer Implementation

In a preferred implementation, direct connections between end-userdevices having virtualized routing capabilities are utilized in a filetransfer context, such as, for example, with a file sharing application.

FIG. 8 illustrates an exemplary file transfer use scenario between twoclients. As described above, each client is in communication with an IPserver, for example to communicate its IP address to the IP server. Suchcommunications are exemplified by steps 1010 and 1020.

In use, a first client communicates to an IP server a request to connectto a particular client, user, or end-user device at step 1030. The IPserver, or control server, determines whether or not the other client,user, or end-user device is available, e.g. online, and, if so, looks upthe current IP address or addresses associated with the specifiedclient, user, or end-user device. If the client, user, or end-userdevice is either not online or has left the network, a connectionfailure message is sent. If the client, user, or end-user device isonline, the IP server will take action based upon a pre-selectedpreference setting. Preferably, each user may choose to acceptconnection requests automatically, require a confirmation of acceptance,or require some other authentication information, such as anauthentication certificate, in order to accept a connection request. Ifthe connection request is accepted, either automatically or manually,the IP server enables the transfer, e.g. by communicating to a secondclient that the first client has a file for transfer, as exemplified bystep 1040.

Preferably, the IP server notifies each client involved in the transferof required security levels and protocols, such as, for example, hashingalgorithms used to confirm that received packets have not been altered.The IP server also insures that the client software at each end-userdevice has not been tampered, altered, or hacked.

The clients complete a messaging “handshake”, and then begin transfer ofa file. More specifically, the second client requests a connection withthe first client at step 1050, the first client notifies the IP serverof its status, e.g. that it is beginning a transfer, at step 1060, thefirst client grants the second client's request at step 1070, and thesecond client notifies the IP server of its status. e.g. that itsconnection request was accepted, at step 1080. The file transfer beginsat step 1090.

Periodically, both clients will update the server on the status of thedownload, as illustrated by exemplary steps 1100 and 1110. The serverwill keep track of the file transfer and compare the informationreceived from both clients for completeness and security. Once the filetransfer is completed, at step 1120, a status is sent of each client issent to the IP server at steps 1130 and 1140, and the connection isterminated at step 1150. The clients continue to update theiravailability with the IP server for future downloads, as illustrated byexemplary steps 1160 and 1170.

It will be appreciated that because one of the problems with the TCP/IPprotocol is that significant timing delays can occur betweencommunications, using a virtual machine advantageously allows messagesto be sent at the lowest levels of the stack between virtual machines ofdifferent clients, thus helping insure that communications are notdelayed. Further, the inclusion of local routing capabilities enableseach client to setup another communication link, if needed, for exampleto continue a stalled download. Further still, as preferably bothclients include such routing capability, either client can reinitiate aseparate communication to the other client, thus helping insure thatTCP/IP packet delay timeouts do not draw out the communication.

Additionally, to facilitate more robust transfers, one of the clientscan instruct the other to open other TCP/IP connections independent ofthe server link. For example, a first client may receive an IP addressfor a second client via the IP server, and the second client could thencommunicate additional IP addresses to the first client and communicateduplicate packets via connections established with these additional IPaddresses, thus increasing the reliability of the link. Additionally,the client could send multiple packets over separate IP addresses toinsure a different starting point for transmission, and thus insureunique paths. It will be appreciated that this might advantageouslyallow for the continuing transfer of packets even if one of theconnection paths fails. Notably, each path is closed upon completion ofthe transmission.

FIG. 9 illustrates a user interface for an exemplary file sharingapplication in accordance with a preferred implementation. To initiate atransfer, a user clicks on an application icon to open the user'sFriend's List and a “Sharzing” window. Bold texted names identifyon-line contacts, while grey texted names indicate off-line contacts.When the blades of the graphical connection representation on the rightside of the window, i.e. the Sharzing, are shut, the Sharzing isinactive. Clicking on an on-line contact opens the blades andestablishes a Sharzing connection. The user may then “drag and drop” afile onto the open Sharzing.

Once a Sharzing connection is established, multiple files can betransferred in either direction. Further, multiple Sharzings can beopened simultaneously to different users. Preferably, when a Sharzing isconnected, wallpaper of the opposite PC that is being connected to isdisplayed. As a file is “dragged and dropped” on the Sharzing, theSharzing displays the progress of the file transfer. Using a Sharzingskin, a Sharzing depiction can take on identities such as, for example,a futuristic StarGate motif. In the case where such a StarGate motif isused, flash wormhole turbulence may begin when a file is placed in theSharzing, and, subsequently, an opening at the end of the wormhole mayemerge to display an image of the file and/or the recipient's desktopwallpaper. Preferably, when the transferred file is visible on thedestination desktop, the transfer is complete.

Many Clients to Many Clients—Video and Audio Conferencing Implementation

In another preferred implementation, direct connections between end-userdevices having virtualized routing capabilities are utilized in atelecommunications context, such as, for example, in an audio and videoconferencing application.

It will be appreciated that in traditional audio and video conferencingapplications, one or more conventional servers act to collate andprocess audio and video streams from a plurality of clients, and thendistribute the processed audio and video streams to the clients. By wayof contrast, in a preferred implementation, an end-user device caninstead establish a direct connection with another end-user device, andcommunicate audio and video directly to the other end-user device,rather communicating through a conventional server. In suchimplementations, this transmitted audio and video can be directlyprocessed by either a communicating end-user device, a receivingend-user device, or both, rather than by a conventional server.

As described above, via the use of virtualization, a first end-userdevice can establish a direct connection with not just one otherend-user device, but with multiple other end-user devices. The firstend-user device provides each other end-user device with its video andaudio stream, thus effectively acting as a server by “serving” its videoand audio stream to each other end-user device. Each of the otherend-user devices involved in a video conference will receive such videoand audio streams served by this first end-user device; however, eachother end-user device will additionally serve its own video and audiostreams. Thus, each end-user device can be characterized as functioningas both a server and a client, possibly at the same time. i.e. as amultiplexed client/server.

Notably, however, although the end-user devices assume somefunctionality more traditionally assumed by a conventional server invideo conferencing applications, a control server is preferably stillused to oversee the establishment and maintenance of connections betweenend-user devices. Unlike in a traditional implementation, however, it ispreferred that little to no audio or video processing is handled at thiscontrol server, and that the audio and video streams between end-userdevices are not routed through the control server.

Instead, the control server primarily provides authentication andsecurity functionality. Preferably, the control server keeps track of aunique identification of each end-user device, software loaded on eachend-user device, and an IP address of each end-user device.Additionally, the control server preferably controls which end-userdevices can communicate, and at what times they may communicate. Forexample, the control server preferably provides functionality allowing amoderator to “talk” over every other user at any given time.

Each end-user device preferably continually provides information to thecontrol server, including: a status of the end-user device, whether theend-user device is receiving audio, whether the end-user device has lostits connection, an application status, application data, whethersoftware at the end-user device has been tampered with, a rate of one ormore communication links, and a packet error rate of one or morecommunication links.

Use with Conventional Servers—Media Server Implementation

In some preferred implementations, direct connections between end-userdevices having virtualized routing capabilities are utilized incombination with one or more conventional file servers, such as, forexample, in a media server application. Specifically, it will beappreciated that the conventional downloading of data, such as a videofile, from a server is an intensive process that utilizes preciousserver processing, memory, and bandwidth. In preferred implementations,some of the strain of this process is offloaded from such a conventionalserver to one or more end-user devices having virtualized routingcapabilities. This architecture decreases the processing, memoryrequirements and bandwidth loads on a media server. Table 2 of FIG. 10shows the relationship for a media file that is being downloaded from aserver when some of the strain of multiple download requests istransferred off of the media server in accordance with such preferredimplementations.

In a preferred implementation, a plurality of end-user devices compriseVDR clients, and a control server comprises a VDR server, eachrespectively including the architecture illustrated in FIG. 11.

FIG. 12 illustrates an exemplary process for downloading media contentto two VDR clients that was originally stored on a customer videoserver, i.e. a media server. Notably, the process involves not just thetwo VDR clients and the media server, but also a VDR server as well.

The process begins when the first VDR client requests download of mediacontent from the media server at step 1210, followed by a correspondingTCP/IP handshake at step 1215. Subsequently, the media server alerts theVDR server of the download at step 1220. The VDR records the activity ofthe first VDR client along with necessary identification and contactinformation for the first VDR client. The media server follows thetypical download procedure and begins the download to the first VDRclient at step 1225.

Thereafter, a second VDR client requests the same media content from themedia server at step 1230, followed by a corresponding TCP/IP handshakeat step 1235. At step 1240, the media server alerts the VDR server tothe download request by the second VDR client. The VDR server determinesthat a VDR client is active, gathers addressing information for thesecond VDR client, and notifies the media server that it will handle thedownload at step 1245. Notably, a VDR client is active as long as itsconnection is active. It will be appreciated that several methodologiesmay be used to determine how long a client stays active. In at leastsome implementations, a client is shut down, i.e. rendered inactive,immediately after a file is transferred, which may represent the mostefficient use of resources. In a preferred implementation, a timer isutilized, and the client remains active a user-specified number ofminutes following activity. Alternatively, a client's connection couldbe left open until the user wants to close it, or until a networktimeout occurs.

At step 1250, the VDR server communicates to the first VDR client andconfigures it for download capability to the second VDR client, e.g.using the obtained addressing information for the second VDR client. Thesecond VDR client initiates communication with the first VDR client fordownload of the media content from the first VDR client at step 1260,followed by a corresponding TCP/IP handshake at step 1265, and thedownload then begins at step 1270.

Notably, the first VDR client, like most clients, has bandwidthavailable on the uplink when downloading content. It is believed that atypical personal computer, as of the filing date of this application,can handle 3-5 uploads without significant burdening or performancedegradation.

Communication between the first and second VDR clients is accomplishedbetween “Thin Virtual Machines” (TVM) of each VDR client. Each TVM ischaracterized as a “thin” virtual machine, as each preferably generallyincludes only functionality necessary to support virtualized networking,and, preferably, optimizes the resources needed to support thevirtualization of the Network Interface Card (NIC). As will beappreciated from the description hereinabove, each TVM enables eachapplication to have a separate virtual interface to the NIC. Thisfunctionality enables customized security capabilities that can be addedto each application interface individually.

At steps 1280 and 1285, the VDR clients convey status information, e.g.concerning the download, to the VDR server. At step 1290, the first VDRclient completes its download of the media content from the mediaserver. The first VDR client continues the download to the second VDRclient, however. While the download continues, status information issent to the VDR server from each VDR client as exemplified by step 1300.Further, the first and second VDR clients continue to communicate viathe virtual machine interface to detect connection issues and reroutepackets.

The download continues at step 1310. At step 1320, the second VDR clientcompletes its download, and each VDR client notifies the server of suchsuccess, as exemplified by step 1330. The VDR server, in turn, notifiesthe media server that the download to the second VDR client wascompleted successfully at step 1340.

If, instead of being completed successfully, the second VDR client'sdownload of the media content had not completed, the second VDR clientwould have contacted the VDR server for another download opportunity.

FIG. 13 illustrates another exemplary process where, rather thandownloading media content from one other VDR client, media content isdownloaded from a plurality of VDR clients, thus increasing the speed ofdownload.

More specifically, a media file is broken into fragments, and eachfragment is downloaded to a target VDR client from a different sourceVDR client using a different connection. In FIG. 13, the process beginswhen, at step 1410, a first VDR client communicates a download requestto a media server, followed by a corresponding TCP/IP handshake at step1415. At step 1420, the media server alerts the VDR server that adownload has been requested. The VDR server determines that multiple VDRclients are available to download the requested media content from, and,at step 1430, the VDR server informs the media server that it willhandle the download request. At steps 1440, 1450, and 1460,respectively, the VDR server communicates to second, third, and fourthVDR clients and passes addressing information corresponding to the firstVDR client to each. The VDR server assigns each VDR client the portionof the media content that that VDR client will download to the first VDRclient.

The first VDR client then downloads, at steps 1445, 1455, and 1465respectively, the assigned portions of the media content from each ofthe other VDR clients. As exemplified by illustration of steps 1470,1472, 1474 and 1476, each VDR client reports to the VDR server statusinformation on any downloads it is a part of, to insure each download isprogressing as planned. If a connection is lost, the VDR server can actto correct the problem. Once the first VDR client has completed thedownload of the media content, it communicates such completion to theVDR server and each other VDR client, as exemplified by illustration ofstep 1480. Subsequently, the VDR server notifies the media server thatthe download was completed at step 1490.

MMORPG Implementation

In another preferred implementation, direct connections between end-userdevices having virtualized routing capabilities are utilized in a gamingcontext, such as, for example, in a massively multiplayer online roleplaying game application.

It will be appreciated that traditional MMORPGs handle the majority ofprocessing for a game world at conventional servers. In a preferredimplementation, some of this processing work is offloaded to end-userdevices having virtualized routing capabilities. For example, eachend-user device preferably functions as a server for serving an avatarassociated with a user to other end-user devices whose users aredisposed, in the game world, in close proximity. In this way, theprocessing associated with such avatars is largely offloaded from theserver.

This offloading, and other similar offloading, reduces the resourcesrequired by an MMORPG server. Notably, however, although the end-userdevices assume some functionality more traditionally assumed by aconventional server in MMORPG applications, a control server ispreferably still used to oversee the establishment and monitorconnections between end-user devices.

The control server preferably provides authentication and securityfunctionality. Preferably, the control server keeps track of a uniqueidentification of each end-user device, software loaded on each end-userdevice, and an IP address of each end-user device. Additionally, thecontrol server preferably controls what actions each client can take.

Each end-user device preferably continually provides information to thecontrol server, including: a status of the end-user device, whether theend-user device has lost its connection, an application status,application data, whether software at the end-user device has beentampered with, a rate of one or more communication links, a packet errorrate of one or more communication links, a game state, a characterstate, and coordinates of the character's location in the game world.

It will be appreciated that voice conferencing can be an important partof the massive multiplayer experience, and, in accordance with one ormore preferred embodiments, functionality and implementation similar tothat outlined in an audio conferencing context is utilized in amassively multiplayer gaming context as well.

Notably, in such implementations, a client both receives informationfrom other clients, for example in the form of avatar information, andadditionally receives information from a content server, which may alsocomprise control server functionality.

Security

Preferably, in secure implementations, clients at end-user devices arealerted by a control server of an impending transfer and utilize asecure protocol such as public key encryption. AES (Advanced EncryptionStandard), or SSL (Secure Socket Layer). Packets to be transferred arepreferably intercepted by a virtual machine of a first client, prior tobeing sent to the network interface of that client, and encrypted.Following receipt, the packets coming out of the network interface arethen intercepted by a virtual machine of the other client and decrypted.

Preferably, strong security is achieved by employing a single encryptionkey that is passed between the two end-user devices controlled at layer2 and 3 of the OSI (Open Source Interface) stack model. Regardless ofwhether the file is transported via Ethernet, WiFi, mobile phone datanetworks, or other wired or wireless technologies, the file is protectedsince it is decrypted at the router level of the destination before thedata is passed to the application.

Although systems, methods, and apparatus are described herein largely inthe context of end-user devices having virtualized routing capabilities,it will be appreciated that at least some implementations may bepracticed in the absence of such virtualized routing capabilities.

Notably, virtualized routing capabilities, such as, for example, thosepresented by a VDR client, may be advantageous even in communicatingwith a client that does not enjoy such capabilities, e.g. a non-VDRclient. In a preferred method, a VDR client in communication with anon-VDR client searches incoming packets for viruses or other anomalies,and, if such other anomalies are found, the VDR client can break offcommunications and re-establish a new connection.

Deflects and Spread Spectrum Networking

FIG. 14 illustrates the use of a dispersive virtual machine implementedas part of a software application that can be easily downloaded to adevice such as a PC, smart phone, tablet, or server. In accordance witha preferred methodology, data to be sent from a first device utilizingsuch software to another device is split up into multiple parts whichare sent separately over different routes and then reassembled at theother device.

FIG. 15 illustrates an exemplary such methodology utilizing one or moresuch exemplary software applications in which a message sent from afirst user's (Joe's) computer to a second user's (Mary's) computer issplit up into three parts, each part is transmitted to a differentdevice also running such an exemplary software application, and eachdifferent device then retransmits such received part to the seconduser's (Mary's) computer. The message is then reassembled and displayedon the second user's (Mary's) computer. In this scenario, each of thethree different devices that the message is communicated to forretransmission can be characterized as a “deflect”, in that rather thansending the message directly to the second user's (Mary's) computer, themessage is first intentionally “deflected” through such differentdevices. Notably, although complete control of routing over one or morenetworks a message will pass through may not be available, by choosingto utilize one or more such deflects, multiple paths can be selected andutilized.

It will be appreciated that splitting a message into three parts andsending such parts over three separate routes makes it more difficult tointercept such message. Leveraging the deflect capability of virtualdispersive routing, packets can be sent independent routes from oneanother, thus ensuring packets cannot be captured by copying packets offthe Internet from a single router.

Different parts of a message could be sent all at once over differentnetwork paths, or, in at least some preferred implementations, a networkpath could be changed over time, for example, a device could beconfigured to utilize a different deflect after a certain period of timeor after a certain number of packets are communicated.

Additionally or alternatively, however, in one or more preferredimplementations, rather than utilizing multiple deflects to send packetsover multiple network paths and/or change network paths, networkcommunications utilize one or more network addresses and/or ports.Preferably, this includes concurrent communication of packets tomultiple network addresses and/or ports of another device, and/orchanging or shifting of the network address and/or port that packets arecommunicated to. Such spreading of packets across multiple IP addressesand ports can be characterized as spread spectrum networking (SSN).

In one or more preferred implementations, by constantly changing the IPaddress and/or ports that a computer device utilizes to talk to anothercomputing device (e.g. P2P (peer to peer) or V2V (virtual machine tovirtual machine)), it becomes much more difficult to track the device.In one or more preferred implementations, virtual machines are utilizedto provide signaling and measure delay between hops.

FIG. 16 illustrates how multiple packets can be sent over differentdeflects in a direct spreading of packets methodology, and FIG. 17illustrates how multiple packets can be sent to different IP addressesand/or ports in a hopping IP addresses and ports methodology.

FIG. 18 illustrates an exemplary system architecture configured to allowclients in a task network to access the Internet through an interfaceserver using virtual dispersive networking (VDN) spread spectrumprotocols.

The exemplary system illustrated in FIG. 18 includes a task network withten VDN enabled client devices, a dispersive presence server, fourdeflect servers, and an interface server. In a preferred implementation,the task network client machines and the interface server will be hostedby a first entity at a particular location or facility, and the presenceserver and deflects will be hosted by another entity at disparategeographic locations.

Each of the task network client machines has installed thereon VDNsoftware that includes a Xen hypervisor with CentOS host operatingsystem containing virtual dispersive networking components. Each clientmachine further includes two Windows guest operating systems. The VDNcomponents are configured to provide connectivity for one of the guestoperating systems to the Interface Server through multiple deflects.This interface server provides access to internet sites such as Googlefor one of the guest operating systems for each of the task networkclients. The VDN components provide connectivity for the other guestoperating system only to the internal task network.

The interface server has installed thereon VDN software that includes aXen hypervisor with CentOS host operating system containing virtualdispersive networking components. The interface server further includessoftware configured to provide connectivity to the internet from theinterface server. Dispersive presence server software and deflect serversoftware is installed on geographically dispersed hosted servers.

All of the client machines and servers are configured to provide desiredconnectivity using virtual dispersive networking. Configuration ofsoftware is preferably adjusted as required based on performance metricsdeveloped through testing.

FIG. 19 illustrates an exemplary system architecture configured toenable a workstation with four independent connections to the internetto send traffic using virtual dispersive networking spread spectrumprotocols to an interface server from each independent internetconnection.

The exemplary system illustrated in FIG. 19 includes a workstationconfigured with four independent connections to the internet andincluding VDN software configured to simultaneously utilize theindependent connections. The system further includes an interfaceserver, a dispersive presence server (DPS), and four deflect servers.

In this exemplary system, the servers are configured as describedhereinabove with respect to FIG. 18, while the workstation is loadedwith VDN software that includes a Xen hypervisor with CentOS hostoperating system containing Virtual Dispersive Networking components.The workstation also has loaded thereon guest operating systems. The VDNcomponents provide connectivity for the guest operating systems to theInterface Server through multiple deflects and through each of theindependent connections to the internet.

Point of Entry Gateways

In one or more preferred implementations, VDN systems use a DPS forconnection processing and collecting network information on a clientpopulation. The connection processing on the DPS communicates with thevirtual networking machines on the end clients to make connectionsbetween the two end-points of the segments that make up a VDNcommunication (that is, two end clients).

In one or more preferred implementations, however, some of thefunctionality handled by a DPS is spawned out to intermediate networkcomputing points (e.g. servers), which can then be in communication withthe DPS. In one or more preferred implementations, one or more point ofentry gateways are utilized in this manner. These point of entry (PoE)gateways, as their name implies, serve as a point of entry for devices(such as end clients) seeking to communicate with the DPS, by receivingcommunications intended for the DPS and forwarding them on (either withor without processing at the PoE gateway).

In one or more preferred implementations. PoE gateways are utilized incombination with a DPS behind a firewall. That is, the DPS remainsbehind a firewall, while the PoE gateways are exposed. Thus, by spawningprocesses out to intermediate network computing points (e.g. the PoEgateways), this enables the database and call processing softwarecontrol of the DPS to remain behind the firewall. The data needed by thePoE gateways will be specific to a particular VDN and also provide othergeneric PoE gateway devices to diversify the network connection.

FIGS. 20-23 illustrate an exemplary scenario utilizing PoE gateways.

An end client 2020 configured for VDN (behind a firewall 2022) seeks toestablish a connection with another end client 2030 (behind a firewall2032). The end client 2020 communicates a message requesting informationfor such a connection to a PoE gateway 2040 of a plurality of PoEgateways, as illustrated in FIG. 20. The PoE gateway 2040 thencommunicates the message on to the DPS 2010 (behind a firewall 2012), asillustrated in FIG. 21. Thereafter, the DPS 2010 communicates connectioninformation to both the end client 2020 and the end client 2030, asillustrated in FIG. 22. The end clients 2020,2030 can utilize thisinformation to set up a connection between one another, as illustratedin FIG. 23.

Although these communications and connections are illustrated as beinggenerally direct (albeit preferably utilizing VDN, as described herein),in one or more preferred implementations, one or more deflects areutilized for any or all of these communications or connections.Specifically, in one or more preferred implementations, split traffic(e.g. VDN traffic with deflects) can be used between two network devices(e.g. DPS and PoE gateway or PoE gateway and VTC (Virtual Thin Client)).For example, FIGS. 24-27 illustrate the same scenario as outlined above,only with one or more deflects utilized for each communication orconnection.

In one or more preferred implementations, such PoE gateways are utilizedto ensure that all devices with important data and network informationare behind a firewall. Further, it is believed that use of PoE gatewaysallows a DPS address to be obscured from network detection.

As illustrated in one or more preferred implementations, more than onePoE gateway can be utilized. In at least some preferred implementations,many PoE gateways can be used, reused and discarded easily.

The use of PoE gateways is further believed to allow system connectionsto be spread out over more computers, thus making a network or systemharder to understand (and thus hack).

Additionally, the use of PoE gateways is believed, in one or morepreferred implementations, to alleviate throughput and connectionlimitations on a DPS, improve scaling, enable multiple points of entry,and provide points of entry that do not contain user data.

Specifically, with regard to this last point, as noted above, networkattacks are a common occurrence in today's cyber environment, andcomputers that are not protected by firewalls are under constant attack.Servers are especially vulnerable due to the fact that they must keep aport open on a firewall to enable a connection to a client. Usingcomputers or devices, such as PoE gateways, that do not have valuableinformation on them as interfaces is believed to be a useful way toprotect user data.

Virtual Dispersive Hand-Off

Traditionally, network connections between different systems typicallydon't hand off connections smoothly or quickly. For example, as a mobiledevice with a WiFi connection moves from a first area, covered by afirst WiFi network, to a second area, covered by a second WiFiconnection, there is typically not a smooth transition from one networkto the other, and instead connectivity will typically be disrupted asthe first WiFi network is lost.

In one or more preferred implementations, however, VDN is utilized for asmooth hand-off. For example, with respect to the previously outlinedscenario, the use of multiple virtual network connections would allowthe device to connect to both WiFi networks, and enable a smoothtransition as the device moves from the first area to the second area.

In one or more preferred implementations, in order to figure out whichaccess points to connect to, several mechanisms are used. Severalexemplary such mechanisms and methodologies will now be described,although it will be appreciated that this is not an exhaustive list.

In one or more preferred implementations, GPS is utilized to determinethe speed and direction of a device and determine network devices inclose proximity for connection.

In one or more preferred implementations, the device detects RF signaland connects to as many devices as feasible. Once connection isachieved, network presence is used to determine the connection point andmove the network connection to the new access point. In one or morepreferred implementations, devices can maintain a connection by usingSpread Spectrum Protocol setups to “roll” the connection and continuestreaming data while moving from access point to access point.

In one or more preferred implementations, by setting up deflects,routing paths and data can be forced to the next access point that amobile device is moving toward. That is, deflects can be utilized toforce traffic to a particular access point.

In some preferred implementations, data is overlapped (e.g. sent to orfrom the mobile device via multiple connections) to insure thatcommunicated information has been or will be received (either by themobile device or by a device it is being sent to by the mobile device),as illustrated in FIG. 28. In one or more preferred implementations,data intended for a mobile device can be preloaded to a deflect andextracted when the mobile device connects to the access point. In somepreferred implementations, data is given a timeframe to exist on thedeflect, and is removed or archived once this timeframe expires, so thatthe deflect is not overloaded with “old” data.

Such hand-off functionality is believed to allow for the use of WiFidevices to stream data to mobile devices while the mobile devices aremoving, allow for the ability to increase the data throughput of asystem, enable the use of inexpensive mobile carrier platforms (e.g.WiFi hotspots and public WiFi), maintain a connection for mobile devicesacross networks and access points, and force traffic (via the use ofdeflects) to an access point for connection to a mobile device.

Multi-Protocol Dispersion

In one or more preferred implementations utilizing VDN, a deflect simplypasses data through without reformatting it. In some cases, then. VDNtraffic can be detected and identified by tracking the data in and outof a deflect. In one or more preferred implementations, a deflect isconfigured to reformat data to another protocol (e.g. from UDP to a TCPconnection) so as to obviate this potential issue. Such a change inprotocol is believed to make it much more difficult for external hackersto detect VDN data and try to put it back together.

As an example, FIGS. 29 and 30 both illustrate exemplary scenariosutilizing a system which includes, inter alia, DPS 2110, PoE gateway2140, two virtual thin clients (VTCs) 2120,2130, and two deflects2150,2160. Specifically, FIG. 29 illustrates VDN routing from virtualthin client (VTC) 2120 to VTC 2130 using two deflects 2150,2160 that areconfigured simply to pass data through. In contrast to this, FIG. 30illustrates a system in which the deflects 2150,2160 are configured toreformat data to another protocol. In the illustrated example, thedeflect 2150 reformats data from HTTP to TCP, and the deflect 2160reformats data from UDP to RTP.

This is believed to make it very difficult for a hacker or monitoringtechnology to detect VDN. Additionally, this allows traffic of one typeto be made to look like another.

Superframes

It will be appreciated that one or more VDN methodologies disclosedherein can be characterized as resulting in VDN traffic that goes in andout of deflects in a 1:1 relationship. That is, in accordance with sucha methodology, each packet received at a deflect is subsequently routedout of the deflect. Notably, however, such VDN traffic can be detectedin and out of deflects due to the 1:1 nature of the traffic.

In one or more preferred implementations, “superframes” are utilized,which represent a single packet or communication that contains twopackets or communications therein, optionally together with instructionsas to where each packet is bound. In one or more preferredimplementations, such a superframe further includes instructions as towhat device should split a superframe up.

For example, FIG. 31A illustrates a first packet 3120 which includesdata A, as well as a second packet 3130 which includes data B. FIG. 31Billustrates a superframe which has been constructed that includes bothdata A and data B. In one or more preferred implementations, suchsuperframe also includes instructions to break apart this data, e.g.instructions as to where to send each set of data, and, preferably eveninstructions as to where this data should be broken apart (e.g. at aparticular deflect). FIGS. 32-33 illustrate a process in which asuperframe is sent from a first virtual thin client (VTC) 3220 to adeflect 3260. The second deflect breaks apart the superframe andcommunicates some data onward toward the second VTC 3230, and some dataonward toward another deflect 3270. The deflect 3270 may then route thepacket towards the second VTC 3230, or somewhere else. In one or morepreferred implementations, a superframe includes instructions as towhere the data contained therein is to be sent. Further, in one or morepreferred implementations, a superframe includes instructions as towhere it is to be broken apart.

Although in the illustrated example the data packets the superframe wasbroken into were communicated onward towards different devices, in oneor more preferred implementations a superframe is broken up but bothpackets continue to be routed along the same path.

Further, although illustrated and described with reference to asuperframe containing two packets or sets of data, in one or morepreferred implementations a superframe may contain three or more packetsor sets of data, which may be bound for different destinations or thesame destination, and may travel the same route or path, or may traveldifferent routes or paths. Further, in one or more preferredimplementations, a superframe might include other superframes nestedtherein. For example, FIG. 34 illustrates a superframe 3410 which itselfincludes a superframe 3420 (which includes two packets 3430,3440) aswell as a packet 3440.

Thus, a deflect can be used as a tool to split a large frame or packinto multiple packets and forward the split packets to other deflectsand/or one or more final destination computing devices.

The use of superframes is believed to facilitate making it verydifficult for a hacker or monitoring technology to detect VDN.

Additionally, superframes can be utilized to facilitate the broadcastingof data to other devices. For example, this could be utilized in supportof one to many type applications.

Application Split Traffic

Typically, applications need to keep track of connection state tooperate and suffer when network connections are poor. In one or morepreferred implementations, virtualization is utilized to insulate anapplication from IP address and network connection duties, which enablesthe splitting of traffic over multiple links. Preferably, communicationsare intercepted at the session layer and parsed out to each link, asillustrated in FIG. 35. For example, traffic from an application can besplit up and parsed out, at the session layer, to a plurality ofdifferent virtual connections. Data received over these connections cansimilarly be reconstructed and passed up to the application. Notably, aconnection can be converted to other protocols for diversity.

This not only provides the ability to split traffic of a connection, butadditionally provides the ability to setup channels to roll a VDN spreadspectrum connection, as well as the ability to hide networkinginformation.

Priority Through Time Measurement

Conventionally, priority of packets through a network is primarilyaccomplished by marking or labeling a packet high priority.Unfortunately, this does not guarantee a fast transfer of data from endto end. For example, not all routers are able to handle or have beensetup to handle special packet markings.

In one or more preferred implementations, VDN is utilized to providebetter end to end quality of service (QoS) without resorting to labelingor marking packets (although it will be appreciated that methodologiesdisclosed herein could be utilized in combination with labeling ormarking packets).

In one or more preferred implementations, a system that can message atthe lowest level in the stack can determine the time it takes forpackets to move from end to end. For example, as illustrated in FIG. 36,first and second end devices 3610,3620 can determine that it takes 100ms to communicate from one end to another through a first deflect, 600ms to communicate from one end to another through a second deflect, and500 ms to communicate from one end to another through a third deflect.

Thus, in this scenario, higher priority traffic from the first enddevice 3610 to the second end device 3620 could be given priority bybeing routed via the first deflect, while lower priority traffic couldbe routed via the second and third deflects.

More generally, if multiple paths are available, end devices can findnetwork connections that give faster end to end throughput and use ofsuch routes and connections can be allocated, prioritized, and/orreserved to devices that can be designated to require higher throughput,such as, for example, emergency management, police, fire, military orother high priority customers and decision makers. Users without as highof priority could have a threshold set of a mid-range time as a minimumthereby keeping the faster routes available for the higher prioritycalls but still enabling the system to enable connections. By choosingconnections with shorter time to send and receive packets, the parallelconnection can actually speed up data being sent between the end points.

In one or more preferred implementations, end devices are designatedwith a particular priority level, which might represent an arbitrarydesignation or could simply represent a minimum and/or maximum thresholdtime.

In one or more preferred implementations, an end device determines thetime it takes packets to travel to a particular destination over severaldifferent routes, and selects a route in accord with its priority level.For example, returning to the example illustrated in FIG. 1, the enddevice 3610 might have a priority level setting a minimum threshold at300 ms, and would accordingly limit its communications to use of thesecond and third deflects (at 600 ms and 500 ms respectively), therebyreserving use of the first deflect (corresponding to a 100 ms traveltime) to higher priority devices/communications.

In one or more preferred implementations, priority designations orminimum or maximum thresholds may be set at an application or connectionlevel rather than on a per device basis, and/or particular applicationsand/or connections may deviate from a device level priority designationor minimum or maximum threshold.

In one or more preferred implementations, priority provision based ontime measurement is believed to provide the ability to give priority topackets without requiring a change to current packets, the ability togive service to lower priority connections without jeopardizing higherspeed connections, the ability to dynamically set time thresholds, theability to give individual devices extremely high priority, allow formeasurement corresponding to end to end priority and quality of servicerather than simply measuring the speed through an individual router.

Multi-Layer Deflects

Systems in which a dispersive presence server (DPS) downloads a spreadspectrum protocol (SSP) to a plurality of virtual thin clients (VTCs)are disclosed herein. In exemplary such systems, a VTC can connect to adeflect that is either specified or chosen from a pool of deflects. Sucha deflect can be behind or in front of a firewall. The deflect thenconnects to a destination or final VTC. Further, in one or morepreferred implementations, a VTC can itself be a deflect (for example, athird VTC can be utilized as a deflect for communications from a firstVTC to a second VTC).

In one or more preferred implementations, rather than simply using onedeflect along any communication route from a source end point to adestination end point, a SSP setup calls out for multi-layers ofdeflects. For example, FIG. 37 illustrates several data paths that passthrough multiple deflects, including a first communication path thatpasses through deflect device 1 and deflect device 3, and a secondcommunication path that passes through deflect device 2 and deflectdevice 5. Although only two layers of deflects are illustrated, in oneor more preferred implementations more than two layers of deflects maybe utilized.

Moreover, multi-layer deflect implementations can utilize the samedeflect multiple times. In one or more preferred implementations, a loopis even set up between two or more deflects whereby data is continuallylooped between such deflects. In one or more preferred implementations,data is stored in a network by being looped continuously betweendeflects. In theory, such data could be stored indefinitely in thenetwork.

In preferred implementations. VTCs are utilized as deflects in order tomake it more difficult to separate traffic originating or terminating atthat VTC from traffic for which that VTC serves as a deflect.

Further, the use of deflects, and multi-layer deflects, is believed tofacilitate obscuring of source and destination IP address information.

VDN Casting

Most communication paths and networks are not 100% reliable. Somecommunication paths will not be available all of the time. In one ormore preferred implementations, VDN casting is utilized to find a way toreach a VTC over varied communication paths.

At times, a destination VTC may be in an area that has limitedcommunication or sporadic communication. In this and similar situations,another VTC can test deflects for connection to the destination VTC. Avirtual dispersive network (VDN) can be rather large, but since themembers of a VDN keep track of connection information (even though adispersive presence server may lose connectivity), the network can stillcommunicate as long as the network has not change significantly and thedestination VTC address had not changed.

FIG. 38 illustrates how a connection from a first VTC to a second VTCthrough a second deflect is still possible even though it is notpossible to connect through a first or third deflect.

In one or more preferred implementations. VDN casting is believed tofacilitate making a network delay tolerant, and allow network devices tobe found at later points in time.

Splits Inside of Splits

In accordance with one or more preferred implementations, dispersivenetworking which splits IP traffic between a source and destinationsignificantly reduces the ability to hack an IP based communicationconnection or packet stream by forcing independent paths using deflects.The spreading of these packets over deflects that are strategicallyplaced on a network (such as the internet) forces a hacker to collectthe packets and figure out how to associate the packets from theindependent paths before the hacker can start to break the encryption. Acommunication that is split and communicated over three different paths(e.g. using deflects) is more difficult to break than a communicationthat occurs over a single path, but it is still possible for a hacker tocollect packets and work to put the packets back together.

For example, FIG. 39 illustrates a system including two end clients thatare communicating over a network that includes three deflects. Eachconnection (or hop) is labeled with an A to indicate that it isassociated with the same split. That is, communication has been splitinto three streams that are each associated with the same split.

Although the system illustrates the use of three deflects, the number ofdeflects could be increased or decreased based on processing power,physical hardware, and security requirements. Preferably, the deflectscan be used and movement of the traffic through new deflects can occurwhile the session communication stream is in process. Preferably, adirect channel (without any deflects) could also be used as acommunication stream along with communication over deflects if anadministrator enables it.

In accordance with one or more preferred implementations, to increasesecurity, IP traffic can be split again either at a deflect and/or at anend client. For example, FIG. 40 illustrates a second splitting ofcommunications from one of the deflects to the second end client. Eachof the connections for the second split (which can be characterized asbeing “inside” of the first split) is labeled with a B to indicate thatit is associated with the second split.

Preferably, such use of an additional split inside of a split operatesto change packet headers, thereby confusing any hacker who is monitoringtraffic. The use of additional splits can also increase reliabilitythrough a network and/or speed up throughput. Splits inside of splitscan be used to help get traffic through a very congested portion of anetwork thereby increasing throughput and reliability of communications.

The use of a split inside of a split also extends the number of hops ina network changing the characteristics of the system to confuse hackers.In accordance with one or more preferred implementations involvingsplits inside of splits, the number of streams forming a second splitinside of a first split is independent of the number of streams in thefirst split.

In accordance with one or more preferred implementations, a system canutilize multiple splits inside of splits, as illustrated in FIG. 41. Inaccordance with one or more preferred implementations, each networkconnection from an end client to a deflect or a deflect to an end clientis a candidate for additional splitting. These connections areillustrated as, and can be visualized as, line segments of acommunication.

In accordance with one or more preferred implementations, each linesegment can be encrypted separately as well as the end to end encryptionof each communication from the source and destination (which representclient devices running endpoint software). In accordance with one ormore preferred implementations, split inside of a split methodologiesare utilized in systems in which encryption is used at the applicationlevel and/or the public key for that application does not transmit inthe open. In accordance with one or more preferred implementations, akey is communicated utilizing splits inside of a split.

In accordance with one or more preferred implementations, techniquessuch as interleaving and insertion of “red herring” data (false data)can be used within a split.

In accordance with one or more preferred implementations, endpoint anddeflect software can be loaded on to the same computing device. Further,in accordance with one or more preferred implementations, multipleinstances of endpoint and deflect software can be loaded on to the samecomputing device, as illustrated in FIG. 42, in which several nodesrepresent devices having both endpoint and deflect software installedthereon. Since endpoint and deflect software can be loaded on to thesame computing device along with multiple instances, additionalcomputing machines are typically not required to do the splitting tohost the multiple instances of software.

FIG. 43 illustrates an exemplary system in which several devices haveboth endpoint and deflect software loaded thereon. Because multipleinstances of deflect software can be loaded on the same device,different streams can utilize different instances of deflect softwareloaded on the same device, as illustrated in FIG. 44. Further, inaccordance with one or more preferred implementations, different streamsmay even utilize the same instance of deflect software.

Additionally, in accordance with one or more preferred implementations,streams passing through a device may be received at or communicated frommultiple, different software instances loaded on that device, andcombined or split at software at the device, as illustrated in FIG. 45.

In accordance with one or more preferred implementations, additionalsecurity is achieved by utilizing a virtual machine running its openguest operating system (e.g. MAC OS, Windows. Linux. or Android), andloading endpoint and/or deflect client software on the guest operatingsystem. By loading client software (e.g. endpoint and/or deflect) on asingle computer, communications between such software may not beavailable to hackers (e.g. available over the public internet). As onlya portion of the total communications would be publicly available tointercept, this would serve to dramatically increase the difficulty oftrying to reverse engineer splits and assemble packets. FIGS. 46 and 47illustrate exemplary systems involving use of a virtual machine havingendpoint and/or deflect client software loaded on a guest operatingsystem.

In accordance with one or more preferred implementations, runningmultiple instances of endpoint or deflect software on a single machinecomplicates the ability of a hacker to “camp” at a choke point in anetwork, copy packets and attempt to decode the headers and put themessage back together.

In accordance with one or more preferred implementations, only a portionof any single split appears on a network (e.g. the internet) if clientsoftware is run on a single machine.

In accordance with one or more preferred implementations involvingsplits inside of splits, similar to use of parentheses in a mathematicalequation, inside or inner splits must be put back together before outeror larger splits.

In accordance with one or more preferred implementations, splits are notalgorithmically chosen so extensive processing power does not help tosteal information, although in at least one or more preferredimplementations splits may be algorithmically chosen. In one or morepreferred implementations, splits are chosen based on networkinginformation.

Based on the foregoing description, it will be readily understood bythose persons skilled in the art that the present invention issusceptible of broad utility and application. Many embodiments andadaptations of the present invention other than those specificallydescribed herein, as well as many variations, modifications, andequivalent arrangements, will be apparent from or reasonably suggestedby the present invention and the foregoing descriptions thereof, withoutdeparting from the substance or scope of the present invention.Accordingly, while the present invention has been described herein indetail in relation to one or more preferred embodiments, it is to beunderstood that this disclosure is only illustrative and exemplary ofthe present invention and is made merely for the purpose of providing afull and enabling disclosure of the invention. The foregoing disclosureis not intended to be construed to limit the present invention orotherwise exclude any such other embodiments, adaptations, variations,modifications or equivalent arrangements, the present invention beinglimited only by the claims appended hereto and the equivalents thereof.

What is claimed is:
 1. A method of communicating data usingvirtualization, the method comprising: (a) spawning, at a first device,a first plurality of virtual machines that each virtualizes networkcapabilities of the first device such that a first plurality of virtualnetwork connections are provided; (b) splitting, at endpoint softwarerunning on the first device, first data for communication to adestination device into a first plurality of data streams; (c)selecting, at the first device by the endpoint software, a firstplurality of deflects for use in communicating the first plurality ofdata streams; (d) communicating each of the first plurality of datastreams using a different one of the first plurality of virtual networkconnections over a different one of the selected first plurality ofdeflects; (e) spawning, at a first deflect of the selected firstplurality of deflects, a second plurality of virtual machines that eachvirtualizes network capabilities of the first deflect such that a secondplurality of virtual network connections are provided; (f) receiving, atthe first deflect, a first data stream of the first plurality of datastreams; (g) splitting, at the first deflect, the first data stream intoa second plurality of data streams; (h) selecting, at the first deflect,a second plurality of deflects for use in communicating the secondplurality of data streams; (i) communicating each of the secondplurality of data streams using a different one of the second pluralityof virtual network connections over a different one of the selectedsecond plurality of deflects; (j) receiving, at a second deflect from afirst set of deflects, the second plurality of data streams; (k)reassembling, at the second deflect, the second plurality of datastreams into the first data stream, and communicating the first datastream onward to another device; (l) receiving, at a second device froma second set of deflects, the first plurality of data streams includingthe first data stream; (m) reassembling, at the second device, the firstplurality of data streams into the first data.
 2. The method of claim 1,wherein spawning, at the first deflect, the second plurality of virtualmachines occurs before receiving, at the first deflect, the first datastream of the first plurality of data streams.
 3. The method of claim 1,wherein receiving, at the first deflect, the first data stream of thefirst plurality of data streams occurs before spawning, at the firstdeflect, the second plurality of virtual machines.
 4. The method ofclaim 1, wherein spawning, at the first deflect, the second plurality ofvirtual machines occurs in response to receiving, at the first deflect,the first data stream of the first plurality of data streams.
 5. Themethod of claim 1, wherein the method further comprises spawning, at thesecond deflect, a third plurality of virtual machines that eachvirtualizes network capabilities of the second deflect such that a thirdplurality of virtual network connections are provided.
 6. The method ofclaim 1, wherein the method further comprises spawning, at the seconddeflect, a third plurality of virtual machines that each virtualizesnetwork capabilities of the second deflect such that a third pluralityof virtual network connections are provided, and wherein receiving, atthe second deflect, the second plurality of data streams comprisesreceiving, at the second deflect via the third plurality of virtualnetwork connections, the second plurality of data streams.
 7. The methodof claim 1, wherein the method further comprises spawning, at the seconddevice, a fourth plurality of virtual machines that each virtualizesnetwork capabilities of the second device such that a fourth pluralityof virtual network connections are provided.
 8. The method of claim 1,wherein the method further comprises spawning, at the second device, afourth plurality of virtual machines that each virtualizes networkcapabilities of the second device such that a fourth plurality ofvirtual network connections are provided, and wherein receiving, at thesecond device, the first plurality of data streams comprises receiving,at the second device via the fourth plurality of virtual networkconnections, the first plurality of data streams.
 9. The method of claim1, wherein the first set of deflects comprises one or more of the secondplurality of deflects.
 10. The method of claim 1, wherein the first setof deflects comprises none of the second plurality of deflects.
 11. Themethod of claim 1, wherein the first set of deflects is the secondplurality of deflects.
 12. The method of claim 1, wherein the second setof deflects comprises one or more of the first plurality of deflects.13. The method of claim 1, wherein the second set of deflects comprisesnone of the first plurality of deflects.
 14. The method of claim 1,wherein the second set of deflects comprises the second deflect.
 15. Themethod of claim 1, wherein the second set of deflects does not comprisethe second deflect.
 16. The method of claim 1, wherein each deflectrepresents deflect software loaded on a distinct physical computingdevice.
 17. The method of claim 1, wherein two or more deflectsrepresent deflect software loaded on the same physical computing device.18. The method of claim 1, wherein the first device or the second devicehas both deflect software and endpoint software loaded thereon.
 19. Themethod of claim 1, wherein one or more deflects represent deflectsoftware loaded on a guest operating system running in a virtualmachine.
 20. The method of claim 1, wherein the method involvescommunication of a data stream between two virtual machines running onthe same physical computing device.
 21. The method of claim 1, whereinthe method involves utilizing encryption for communications betweennodes.
 22. The method of claim 1, wherein the method involves utilizingnode-to-node encryption for communications between nodes in combinationwith end-to-end encryption for the entire communication from the firstdevice to the second device.
 23. The method of claim 1, whereinapplication-level encryption is utilized.
 24. The method of claim 1,wherein public-key encryption is utilized and a key is communicatedutilizing a methodology involving splits inside of splits.
 25. Themethod of claim 1, wherein interleaving is utilized inside of one ormore splits.
 26. The method of claim 1, wherein the insertion of redherring data is utilized within one or more splits.
 27. The method ofclaim 1, wherein selecting, at the first device by the endpointsoftware, the first plurality of deflects for use in communicating thefirst plurality of data streams comprises selecting the first pluralityof deflects based at least in part on networking information.
 28. Themethod of claim 1, wherein endpoint software is loaded on a desktopcomputer.
 29. The method of claim 1, wherein endpoint software is loadedon a laptop computer.
 30. The method of claim 1, wherein endpointsoftware is loaded on a tablet.
 31. The method of claim 1, whereinendpoint software is loaded on a smartphone.
 32. The method of claim 1,wherein endpoint software is loaded on a smart watch.
 33. The method ofclaim 1, wherein endpoint software is loaded on a wearable computingdevice.
 34. The method of claim 1, wherein endpoint software is loadedon a smart appliance.
 35. The method of claim 1, wherein deflectsoftware is loaded on a desktop computer.
 36. The method of claim 1,wherein deflect software is loaded on a laptop computer.
 37. The methodof claim 1, wherein deflect software is loaded on a tablet.
 38. Themethod of claim 1, wherein deflect software is loaded on a smartphone.39. The method of claim 1, wherein deflect software is loaded on a smartwatch.
 40. The method of claim 1, wherein deflect software is loaded ona wearable computing device.
 41. The method of claim 1, wherein deflectsoftware is loaded on a smart appliance.
 42. A method of communicatingdata using virtualization, the method comprising: (a) spawning, at afirst device, a first plurality of virtual machines that eachvirtualizes network capabilities of the first device such that a firstplurality of virtual network connections are provided; (b) splitting, atendpoint software running on the first device, first data forcommunication to a destination device into a first plurality of datastreams; (c) selecting, at the first device by the endpoint software, afirst plurality of deflects for use in communicating the first pluralityof data streams; (d) communicating each of the first plurality of datastreams using a different one of the first plurality of virtual networkconnections over a different one of the selected first plurality ofdeflects; (e) spawning, at a first deflect of the selected firstplurality of deflects, a second plurality of virtual machines that eachvirtualizes network capabilities of the first deflect such that a secondplurality of virtual network connections are provided; (f) splitting, atthe first deflect, a particular data stream of the first plurality ofdata streams into a second plurality of data streams; (g) selecting, atthe first deflect, a second plurality of deflects for use incommunicating the second plurality of data streams; (h) communicatingeach of the second plurality of data streams using a different one ofthe second plurality of virtual network connections over a different oneof the selected second plurality of deflects.
 43. A method ofcommunicating data using virtualization, the method comprising: (a)splitting, at endpoint software running on a first device, first datafor communication to a destination device into a first plurality of datastreams; (b) selecting, at the first device by the endpoint software, afirst plurality of deflects for use in communicating the first pluralityof data streams; (c) communicating each of the first plurality of datastreams over a different one of the selected first plurality ofdeflects; (d) splitting, at the first deflect, a particular data streamof the first plurality of data streams into a second plurality of datastreams; (e) selecting, at the first deflect, a second plurality ofdeflects for use in communicating the second plurality of data streams,(f) communicating each of the second plurality of data streams over adifferent one of the selected second plurality of deflects.
 44. One ormore computer readable media containing computer executable instructionsfor performing a disclosed method.
 45. A system for performing adisclosed method.
 46. Software for performing a disclosed method.
 47. Asystem as disclosed.
 48. A method as disclosed.
 49. Software asdisclosed.